[GEP-17] Add GEP-17 with an updated Control Plane Migration "Bad Case" Scenario description #4107
Conversation
gardener-robot
added
area/control-plane-migration
|
@stoyanr Label priority/normal does not exist. |
gardener-robot
added
needs/review
size/M
stoyanr
changed the title
|
/cc @plkokanov @kris94 |
|
We consider this PR as ready for review now. |
|
/cc @amshuman-kr @vlerenc |
gardener-robot
added
the
lifecycle/stale
stoyanr
changed the title
|
@stoyanr Label priority/normal does not exist. |
|
/cc @plkokanov @kris94 @rfranzke @timebertt @vlerenc @amshuman-kr @mandelsoft @MartinWeindel To make the bad case scenario description easier to understand and discuss, I moved it to a new GEP (GEP-17). It was independent from the old GEP (GEP-7) already which is already implemented and released. The new proposal is very different from the original one proposed about 3 months ago. It is significantly simpler, as it is based on the owner DNS records that could be meanwhile introduced after the DNSRecords feature was implemented. There are no more I resolved all existing comments, since they were either no longer relevant (regarding parts that have been removed), or sufficiently well answered (at least from my perspective). As before, everything you see in the proposal has been implemented and tested as part of the PoC, and the productization of certain parts (copying of snapshots) is already ongoing. |
|
/touch |
gardener-robot
removed
the
lifecycle/rotten
|
Thank you @stoyanr and colleagues. The new proposal can be understood very well and seems safer and also easier to build. A question that I would have is what happens if the destination seed cannot access the source seed's backup bucket. Should that happen, the migration needs to be put on hold (possibly indefinitely) as without a backup/snapshot there is no point in bringing back the cluster as it would be empty. How will this be guardrailed? |
Yes, this is what will happen. The copying of snapshots task will fail, and the restoration flow will keep retrying it until it eventually succeeds, or until the shoot is marked as |
|
@rfranzke Thanks for your feedback! I added a new section to the GEP regarding Handling Inability to Resolve the Owner DNS Record and I answered all your other comments. I think no other changes to the GEP are required, let me know if you still miss something. |
stoyanr
force-pushed
the
update-gep-7
branch
from
c567bdc
to
6b55fc1
Compare
…" Scenario description (gardener#4107) * Remove old base case description * Update GEP-7 with a new bad case scenario description * Move CPM bad case description to a new GEP * Update GEP-17 with the latest PoC changes * Add Handling Inability to Resolve the Owner DNS Record section
…" Scenario description (gardener#4107) * Remove old base case description * Update GEP-7 with a new bad case scenario description * Move CPM bad case description to a new GEP * Update GEP-17 with the latest PoC changes * Add Handling Inability to Resolve the Owner DNS Record section
How to categorize this PR?
/area control-plane-migration
/area documentation
/kind enhancement
/priority normal
What this PR does / why we need it:
Which issue(s) this PR fixes:
Part of #1631
Special notes for your reviewer:
This PR supercedes #3066. While it builds upon the same main ideas, the description is restructured and aligned with the results of the PoC.
Release note: